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The Design Realization, Evaluation And Modelling (DREAM) System is eval- 
uated, A short history of the DREAM research project is first given in 
order to provide an historical context. Then, the significant charac- 
teristics of DREAM as a development environment are given, the design 
notation which is the basis for' the DREAM system is reviewed, and the 
development tools envisioned as part of DREAM are discussed. In the 
concluding section, insights into development environments and their 
production which we have gained from the work on DREAM are presented 
and used to make suggestions for future work in the area of develop- 
ment environments. 
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During software system development, help is critically needed in many activities, 
among them: l) recording what is known and what has been decided about the sys- 

tem, 2) uncovering what is unknown, 3) assessing the suitability and the complete- 
ness of the (eventual) system, and 4) coordinating and monitcv^ing the efforts of 
the team working on the development project. 

Development environments are currently being studied as a way of providing help 
for these activities. A development environment is a collection of tools which 
provide a facilitating context in which to carry out development. The tools are 
typically programs, such as compilers or text editors, which augment the "powers" 
of the developers and ease the production of a suitable, executable version of the 
system. But, tools may also be notational and serve to augment the developers' 
denotational powers , or cognitive and serve to rationalize the development process. 

In this paper, we give an assessment of the Design Realization, Evaluation And 
Modelling (DREAM) System as a develo[)ment environment. In the next section, we 
give a short history of the DREAM project in order to provide seme historical con- 
text. Then, in the following three sections, wc discuss the significant charac- 
teristics of DREAM as a development environment, give a brief overview of the 
notational tool which is the basis for the DREAM system, and discuss the other 
tools provided (or to be provided) by DREAM. In the concluding section, we relate 
some of the insights into development environments and their production which we 
have gained from our work on DREAM. 


A SHORT HISTORY 

Like most systems, DREAM is a product of initial goals, prior experiences, biases 
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and external "forces." In this section, we provide a brief history of the DREAM 
project with the intent of providing sonic insight into the technical and non-tech- • 
nical concerns which influenced the 'Solution of the DREAM system. 

During the period 1973-1975, an aut(<i!iata theoretic forinnlism for modelling parallel 
systems was developed and its theoretical aspects were investigated (this work is 
reviewed in [Riddle 79d] and [Riddle 79el). Under the formalism, a parallel system 
is considered to be a single-level eol lection of asynchronous components. Component 
interdependencies are modelled by message exchange and some components provide mes- 
sage buffering capabilities. The nofi-buffering components are modelled as sequen- 
tial processes which carry out a controlled sequence of message production, trans- 
mission and reception operations. A parallel system's behavior may be described 
in terms of sequences of message transfers among components using a notation very 
similar to, but more powerful than, the notation of regular expressions. The ex- 
istence of dual behavior/structure^ notations affords the opportunity to assess 
the "correctness" of a par cicular system structure by assessing the consistency 
between the behavior produced by the structure and a specification of the system's 
desired behavior. However, the power of the formalism is such that very few con- 
sistency questions are algorithmically decidable. 

Concurrent with this research, the TOPD system, developed by Peter Henderson and 
his colleagues at the University of Newcastle upon Tyne ([Henderson 75b]), was 
acquired and used as the basis for a senior-level software engineering course. 

The TOPD system is a development environment oriented primarily toward the im- 
plementation phase of sequential program development. It allows the development 
of a program to be done as a series of abstract descriptions, each of which is 
a finite-state model organized as a collertinn of data abstractions. The TOPD 
notation allows the description of behavior in terms of state transitions and the 
TOPD system provides assessment facilities [Henderson 75a] which allow the check- 
ing of the consistency between a procedure's behavior 1 and structural descriptions. 

It was in this context that the DREAM project began, in early-1976, with the in- 
tent of preparing a prototype version of a TOPD-like system useful for the develop- 
ment of concurrent software systems. Sycor, Inc., provided support because the 
prototype was potentially useful in developing software for clusters of intelligent 
terminal s . 

The project was decidedly a research one, however, and was not driven in any way 
by a particular software development effort at Sycor or elsewhere. One goal was 
to investigate the feasibility and desirability of basing a concurrent software 
system development environment upon the theoretical model of parallel systems which 
had been developed. An equally strong goal was to provide a basis for the exper- 
imental evaluation of development environments and methodologies. Our aspirations 
in the latter direction followed from our feeling that experimental evaluation 
required the ability to perform well-defined, analyzable, partial development 
efforts and our' belief that a development environment supporting modelling pro- 
vided this ability. 

Initially, our efforts focused upon developing a notation primarily founded upon 
our model of parallel systems but whicn utilized some notions from general sys- 
tems theory and incorporated some compatible concepts from the TOPD Notation. We 
blatantly stole the general structure of the TOPD notation, as well as its concept 
of state-based models for describing data abstractions, but used our model of par- 
allel systems as the conceptual basis for our notation and extended the state- 
based model adopted from TOPD. The result was the DREAM Design Notation (DDN) 
which will be discussed in a subsequent section. 
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During its development, we used DDN in several description tasks in order to as- 
sure ourselves that it was both effective and reasonably natural for describing a 
relatively broad variety of systems including operating systems, process-based 
problem solving systems and embedded control systems. Most of our description 
"experiments," however, concerned operating systems or parts of operating systems, 

We also adopted the TOPD system's organization and prepared preliminary versions 
of many of the components of a prototype DREAM system - a data base, a syntax 
checker and a command interpreter. Integration testing of these components was 
precluded by the disbanding of the research group in late-1977. Several of us 
moved to other institutions, and we took advantage of the interruption in our ac- 
tivity as a group to both prepare reports and critically examine what we had done. 

Oves the last two years, our critical examination has been broadened to consider 
a number of specific topics which arose during our development of DDN. Some of 
these studies concerned the extension of DDN's conceptual base to a broader spec- 
trum of systems ([Wileden 78a], [Segal 80]). We also investigated both the rela- 
tionship of our work to system's theory [Riddle 79b] and the nature of a top-down 
design methodology based on dual behavior/structure notations such as DDN 
[Riddle 79c]. Finally, we have been developing algorithms that can be used (in 
modified form) to assess the consistency of DDN descriptions ([Bristow 79], 
[Stavely 79]). 

At the moment, the research group is distributed and loosely-coupled. Each of us 
has a different focus to our individual work (flight control system design, dis- 
tributed problem-solving system development, analysis algorithm development), but 
our work is somewhat integrated through our previous joint efforts. 


THE DREAM SYSTEM 

A wide variety of systems may be called development environments - even current- 
day operating systems are, in some sense, development environments. The different 
possibilities may be distinguished by characteristics such as the system's method- 
ological base, the development phases sup()orted, the intended audience, etc. In 
this section, we "define" the DREAM system in terms of a number of these distin- 
guishing characteristics. 


Concurrent Systems qp pnr^ IB 

OR quality 

As indicated previously, DREAM is oriented toward the development of concurrent 
systems, i.e., systems having parts which either actually or logically operate 
in parallel. We have not restricted attention to any specific type of concurrent 
systems and feel that DREAM is applicable to a wide variety including multi - 
programmed systems, multi process systems, multiprocessor systems, netv/orks and 
distributed systems. In DDN, we have provided a set of description capabilities 
which are appropriate for conceptualizing systems of any of these types even 
though these types differ extensively with respect to some characteristics. As 
a corollary, DDN does not have facilities for describing those aspects, such as 
the allocation of processes to processors, which distinguish these different types 
of concurrent systems (although these aspects con sometimes be indirectly 
described) . 

Our orientation toward this general class of software is not solely because of 
our previous work on a formalism for describing parallel systems. Rather, it is 
our belief, confirmed by our own and others' experiences, tiiat the development 
of concurrent systems is particularly taxing, especially with respect to the 
assessment of suitability. 


Design Phase 

DREAM is oriented toward the m'flii t( drr.hni phase of software development. 

In this early segment of the total cii-sign phase, the task is to delineate the sys- 
tem's modules and define the cbuplings among modules.’ Thus, attention is primarily 
upon decomposing a system into its parts, defining the parts' interfaces, and in- 
dicating the interactions and interdependencies among the parts. 

The architectural design phase is preceded and followed by other phases -■ indicat- 
ing what these entail serves to delimit the architectural design phase even fur- 
ther by indicating what it does not, entail. Preceding the architectural design 
phase are the noquivamcnts definition and iqn'olfiontion phases during which the 
system's overall capabilities are prescribed. Following the architectural design 
phase are the aLjonit.lun doniqn and the I'nri.oni !i';i';.rmo)ii(itio}i phases during which 
the information structuring and manipulation aspects of the system are detailed 
and encoded in some executable form. Thus, sandwiched as it is between these other 
phases, a primary purpose of the architectural design phase is to transform the 
requirements levied against the entire system into information retention and man- 
ipulation requirements to be satisfied by the system's components. 

Implicit in this view of the system lifecycle is that system certification and 
maintenance are not separate phases. Rather, certification, by either verifica- 
tion or validation approaches, is viewed as a continual concern which must be per- 
formed during ovon,< phase. Maintenance is viewed as regression to some previous 
point in the development followed by re-development. Thus, the activities of 
certification and maintenance are improtant during the architectural design phase 
and it is our intent to support these activities in DREAM. 


Total System 

In many applications, the components of a concurrent system are physical ones 
(e.g., aircraft engines) or human ones (e.g., a patient being operated on) as v;ell 
as software. DON allows the consideration of the total system (ha)’dware, wetware 
and software) and thus permits the design of the software to be carried out with 
full concern given to the environment in which the software will function. 


Model ling 

It is our belief that the .fundamental activity during architectural design is 
modelling — in fact, the name "architectural design" was chosen to deliberately 
suggest a relationship to the discipline of architecture in which the preparation 
of schematic, conceptual models is a paramount concern. The models developed 
during the archi tectural design of software (or buildings) are abstract repre- 
sentations of the actual system which omit the system's fine detail but faith- 
fully reflect its externally observable characteristics. In these abstract rep- 
resentations , whatever is represented is done so to a level of accuracy and rigor 
that there is an adequate basis for suitability assessment. Also, the I'epresenta- 
tions are in a medium in which alterations may be more easily investigated. 

The analogy to architecture indicates one additional aspect of the design-level 
modelling of software. This is that there are at least two purposes of a model. 
One is that indicated above — it should reflect externally observable character- 
istics. The second purpose is that the model should be an adequate basis for 
preparing implementation plans (blueprints). DDN is intended as a medium in 
which models with either or both of these purposes can be prepared. 


Functional i ty 
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work has been done on assessment with respect to performance concerns 
([Sanquinetti 77], [Snnquinetti 78], [Sanquinetti 79]) at the level of the con- 
cep-tual basis underlying DON, but tfo orientation of DUN itself is exclusively 
upon the description and assessment of a system's functional characteristics, 

This focus was taken in order to reduce the scope of our work to a manageable 
size rather than because of any feeling that performance or economic concerns are ’ 
of less importance. Much to the contrary, we feel that truly effective environ- 
ments must support the assessment of systems with respect to these other concerns; 
but we also know that facilities to allow such assessment are extremely difficult 
to provide. 


Decision-making Support 

As noted, certification is considered to be a continuous activity that is well- 
integrated with the activity of design preparation. It is an intent of DREAM 
that designers be able to not only gradually evolve a design but also be able to 
gradually evolve a defensible confidence in the suitability of that design. Thus, 
DREAM includes a number of tools which guide the decision-making process, allow 
the recording of decisions, and help designers determine the validity of their 
decisions. In DREAM, decision-making guidance is supported by tools which help 
designers identify unmade decisions and the information impacting the decisions. 
Decision recording is aided by providing appropriate rotational tools (i.e., 
languages). Decision verification is aided by toois which allow designers to see 
the results, in terms of the system's functionality, of a decision iv the context 
of all previous decisions. 

To date, our accomplishments have fallen short of our intentions and we liave fully 
developed only one decision-making tool, the DDN notation for recording decisions 
in terms of their effect on the structure and behavior of the system's components. 
We have developed other techniques, discussed later, for decision verification, 
but have not put these into a form compatible with DDN. 


Methodology Independence 


OUTGINSC PSGE IS 
OF POOR QUALITY 


Because of our goal to provide a facility for the evaluation of a variety of 
methodologies, and because of our reluctance to posit a universally applicable 
methodology, we attempted to keep. DREAM as free of methodological constraints as 
possible. This did not, however, mean to us that we could not make the system 
easier to use under one methodology ^nd our proclivity toward top-down elabora- 
tion is quite apparent in the DDN language. 


One effect of this decision is that DREAM does not enforce the use of any par- 
ticular tools at any particular points during design evolution. Our view of the 
DREAM systeii) user (which we adopted from TOPD) is that of a person who thinks 
off-line and then uses the system to heV,) keep track of decisions and periodi- 
cally derive information by which tiie logical consequences of the decisions may 
be deduced. As a consequence, DREAM does vo:. preclude the entry of new informa- 
tion concerning the design which is incompatible with existing information. 

Rather, DREAM enforces only the rule that all information is syntactically correct 
and provides tools through which designers may uncover incompatibilities and in- 
consistences when warranted by whatever design "style" they use. 


Language-based Integration 

While DREAM does not achieve the integration of its tools by organizing them 
around a unifying methodology, it should be apparent from the discussion so far 
that it does follow the alternative approach to integration by basing the tools 
upon some common notation. The DDN language and the view of software systems 
. ^4. .1 /•■nmrnrm hAci*; f nr dpf ini nu thp tnoI<: ftiPir 
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relationships in terms of how they construct, modify and manipulate descriptions 
in the language. The tools themselves make extensive use of both the syntactic 
and the semantic aspects of DDN. 

In actuality, DDN is a collection of compatible sub-languages. Therefore, DREAM is 
more correctly characterized as being integrated on the basis of a family of com- 
patible languages. Anyone who has worked with "large" programming languages will 
appreciate the desirability' of having a collection of "small," well-defined lan- 
guages where attention has been given to separation of concerns. 


"Sophisticated" Users 

DREAM is intended to be used by experienced design practi tioners . Provision is 
made to represent information of interest to both requirements definers and system 
implementors, but it is assumed that the design practitioners will function as 
interpreters of the information for these other concerned parties. Mo attempt has 
been made to make DREAM usable by managers, end-system users, customers, docu- 
mentors, testers, accountants, etc., all of whom have a legitimate concern in the 
design and its implications. DREAM can, in some instances', represent the informa- 
tion of interest to these agents, but the designers are again assumed to provide 
an interpretive interface to this information. 


DREAM DESIGN NOTATION 

The heart of the DREAM system is the DDN language. It embodies a formalism which 
facilitates the conceptualization of concurrent software systems during their 
architectural design. Also, it is the basis for the integration of the tools pro- 
viding aid to design practi ti'oners. Before describing these tools, it is necessary 
to give a brief overview of the DDN language and that is the purpose of this sec- 
tion. More detail on the DDN language can be found in the cited reports or inferred 
from the example that appears in the Appendix. 


Structural Models 

In DDN, a system is modelled as an hierarchical, but not necessarily tree-like, 
organization of components which operate asynchronously. At each level in this 
hierarchical decomposition of the system, components interact directly by the 
transmission of messages or indirectly through shared information repositories. 

Components which interact by message transiin ssion are called subs'jcUcnr 
([Riddle 77], [Riddle 78a], [Riddle 78b]). At each level, the subsystems represent 
the components which operate concurrently. Each subsystem's interface to its 
environment (i.e., the other subsystems ai the same level) is defined in terms of 
through which messages may flow. The components within a subsystem know only 
about the ports - the environment of the subsystem is not visible to the subsystem's 
components. Likewise, the environment knows only about the subsystem's ports and 
cannot "see" inside the subsystem. Thus, the subsystem's interface is akin to a 
data abstraction interface with the ports serving a role analogous to a data ab- 
straction's procedures. 

Some of a subsystem's components are primitive, that is, not decomposible. These 
contyol processrn govern the flow of messages through the ports and serve to dis- 
tribute incoming messages to component subsystems and to collect messages from 
component subsystems for transmission out through the ports. Control processes may 
communicate directly by message transmission. Also, they may communicate via 
shared information repositories. 

In Figure 1, we nive a grci,-.i,^al repr^ nion of a DDN model using circles to 
denote subsysto; , triangles to denote cont>'ol processes and squares to denote 
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"skin." The small, black squares in the figure are special shared data repos i'" ' 8 

tories, called Hnkn^ which provide potentially infinite message buffering 
facilities. This figure more clearly indicates that subsystems provide theineans 
for encapsulating collections of data storage components (internal, shared informa- 
tion repositories) and data processing components (internal subsystems). Note thac 
component-sharing is allowed, even between levels of decomposition. 

Shared data repositories are modelled as [Hoare 74] since this well-known 

construct provides much of what is needed [Riddle 79a]. A monitor in DDN denotes 
a multi -procedure data abstraction which can function as a data repository shared 
among asynchronous data processing components. There is the restriction that only 
monitors may be components within monitors. (This somewhat arbitrary restriction 
comes from a feeling that once a locus of control is sequential i zed it should re- 
main sequential ized. ) 


Behavior Models 

A structural model reflects operational aspects of the system specifying interfaces 
and modelling the algorithms which control the use of the interfaces. This is 
analogous to defining the structure of a stack data abstraction and the structure 
of a tree-search algorithm Which uses a stack by specifying the push and 292. P*”o- 
cedures and giving an abstraction of the tree-search algorithm which indicates, 
non-deterministically, the calls upon the £usjn and jopJl procedures. 

A structure gives rise to, or causes, some behavior which is the effect, over time, 
of "executing" the structure. Thus the beliavior of a stack data abstraction is 
reflected by statements such as "the number of £ 0 £'s is less than or equal to the 
number of push 's," and the behavior of the stack as used by the tree-search al- 
gorithm i s refl ected by statements which indicate the sequences of po£'s and 
push ' s which the algorithm creates when it is executed. 

Notice tliat a compOf'ent will have an inivinaia (or actual) hchavicn< which is the 
behavior the component's structure is capable of producing. A component will also 
have one or more cxtvb\r>ic (or dar.ivri) behaviors which are those stemming from 
the use of the component. In the absence of any knowledge of about how a compon- 
ent is actually used, its vc‘quh>.:d hchavi.a» can be defined with the implication 
that any legal extrinsic behavior should exercise the component only in ways that 
are indicated in the required behavior. DREAM'S certification tools, which will 
be discussed later, determine suitability by comparing extrinsic, required and/or 
intrinsic behaviors. 

DDN provides a number of ways of specifying a component's required behavior and 
thus giving a behavioral model of the component ([Riddle 78b], [Wileden 78b]). 
Required behavior that relates to the usage of interfaces may be specified by in- 
dicating conditions upon the information which may legally pass through the inter- 
face. Thus, conditions may be levied against messages that may pass through 
subsystem ports or values that may "t'ass through" parameters to monitor procedure 
calls. 

More complicated aspects of a monitor component's behavior, concerning when the 
component's procedures may be legally invoked, may be specified by giving pre- 
and post-conditions, stated in terms of the "stijte" of the component and associated 
together to form a transition which indicates the effect of the procedure. For 
example, a stack's states could be specified as empty , ful 1 , and otherwis e and the 
transitions for pop could be: 



otherwi se 


otherwi se 


otherwise or empty 


which indicate that -annot be leg.;,.,; invoked when the stack is enif^ty 
and specify t'-- reoun-uu behavior to be "caused" when pop is invoked” (The 


specification of behavior by state transitions is a concept which we borrowed from 
TOPD.) 

A final set of DDN constructs for spucifyinc] required behavior allows the descrip- 
tion of behavior over time, hhu-ui:^ '.an bo defined as the occurrence of "interest- 
ing happenings" during system operation and the required behavior may then be ex- 
pressed as required sequences of events. For example, procedure names are auto- 
matically events and the usual required behavior for a stack could be specified as 

Ri:ENTRANT(SEQUENCE(push, popj ) 

which, because of the semciritics of REENTRANT, means that the number of push 's 
must be greater than or equal to the number of pop's. 

The DDN constructs for event sequence definition are powerful but parsimonious. 
Also, they are a formal notation and are therefore not extremely "friendly" for 
design practitioners who lack training in the formal aspects of computer science. 
However, they provide a set of denotational capabilities which are extremely im- 
portant for behavioral modelling. 

omaimt pxge is 

Organizational Model Ofi EOOR QUALITY 

Following the precedent set by the TOPD language (and originated, we believe, in 
the Simula language [Dahl 66]), DDN descriptions are a collection of aL:t'n defini- 
tions. A model is therefore obtained from a description by a process of inoLaii- 
tiaiim. Standard declarative constructs are used to denote hierarchical organ- 
ization and special constructs ore provided to denote component sharing since the 
standard declarative constructs would permit only tree-like hierarchies 
[Riddle 80]. Message communication pathways among subsystems are defined by using 
additional descriptive constructs. 

DDN views instantiation as occurring entirely before execution and thus models 
have a static organization. Many dynamic organizations can, however, be 
"simulated" by the dynamic use of a static communication pathway organization, 
but the resulting models tend to be overly complex and unclear. 


A Final Word 

DDN is a poor programming language; but that's because it is not intended to be 
a programming language. The intent in developing DDN is to provide modelling 
constructs which allow the description of what modules comprise a system and what 

the interactions among the modules should be. Exactly 'now the modules interact is 

not considered to be properly part of a DDN model. Thus, for example, a single 
concurrent process synchronization mechanism (message transfer) is provided in 
DDN whereas Lne actual synchronization in the fully developed system would be 

achieved by the use of one of a number of synchronization mechanisms. 

However, DDN looks like a programming language and this is perhaps a mistake. 

We have seen designers misled by the similarity and, as a consequence, they mis- 
use the language. We feel, however, that the concepts included in DDN are the 
right ones for the archi tectural design of concurrent systems. We feel that the 
problems which arise should be solved by education of the designers rather than 
changing DDN. 


DREAM SYSTEM TOOLS 

We plan a number of tools to help design practitioners in constructing suitable 
models for concurrent software systems. We know that some of these tools are 
feasible because we have constructed prototype versions. Others have been de- 


» 

put them in a form suitable for use with DDN. We discuss thesetools in this sec- ^0 
tion as if they have been constructed and the cited references indicate more ex- 
actly the degree to which they have been developed. 


Data Base Core 

The fundamental tool in DREAM is a data base in which are stored fragments of a 
DDN textual description. Most fragments define some aspect of some class of com- 
ponents in the model; others give information concerning tests or analyses, doc- 
umentation, etc. The DDN syntax defines how these fragments are related and 
provides for naming them. Fragments to be retrieved from the data base are 
selected by these names and thus DDN itself is used as the basis for the data base 
query language. 

Description fragments have other attributes besides names. In the current data 
base implementation [Humbrecht 80], there can be an arbitrary number of addi- 
tional attributes although the number of attributes and their values are fixed 
for any data base. Further, there must be at least one attribute which hold a 
time/date stamp reflecting when the fragment was inserted into the data base, 

Users may establish a "slice" through the data base by specifying values for the 
attributes and any modifications to the data base are relative to the fragments 
in the active slice. The time/date stamp attribute is used to resolve all ambi- 
guities, in effect selecting the "newest" fragment in any collection which is 
selected by an ambiguous retrieval command or slice definition. This data base 
organization provides a good deal of flexibility, allowing "windows" into the 
data base which can reflect time, versions, design team organization, etc. 


Bookkeeping Tools 

In keeping with the view that a DREAM user intersperses relatively long periods 
of offline thinking with relatively short periods of modification of the infor- 
mation contained in the data base, the DREAM tools for aiding the maintenance 
of the evolving design's description are simple extensions of the data base inter- 
face. It is assumed that the host operating system's editor can be used to pre- 
pare new or modified description fragments. The bookkeeping tools then amount 
to 1) an entry tool which syntax checks the fragment and presents syntactically 
correct fragments to the data base for insertion, and 2) a retrieval tool which 
interprets the user's retrieval directives and constructs the appropriate data 
base query commands. 


Decision-making Tools 

The major tools provided by DREAM are those which aid design practitioners in 
assessing the suitability of the design as it evolves and in identifying what 
remains to be designed. These tools fall into three categories which we discuss 
below. 

Phav iphvar, iruj TooTr,. Tools in this category re-present the information in the 
data base in a form, perhaps structured in some canonical format or presented 
graphically, in which the user may more easily inspect it and perhaps even iden- 
tify some errors. The information is no more and no less than that already con- 
tained in the data base although the use- may focus on some subset of the total 
information. Figure 1 is an example of vhat might be produced by an instantia- 
tion graph paraphrasing tool. Other paraphrasing tools could produce control 
maps akin to flow charts or they could produce cross-reference charts. 

Extraation Tooln. Th' type of tool exai ines the information in the data base 
and, knowing the sp'^' "s of DDN, derives feedback -or the designers concerning 
the character 'Sties u. e/ie model. Usually, this feedback concerns the intrinsic 

V- ^ . ..•il »» I 1. .W. « .J ^ 1 e- A. 
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simulators, finite-state testers [Henderson 75aj, .ukI event sequence expression n 
derivers [Riddle 79e], 

Corxslui.hi'K cluh.'kfuj These tools unerver incoinpatibiUtios among various 

description fragments or oetween a description ir.igiiient and *.ome rule (e.g,, no 
deadlock). Because of the difficulty and impo. • iid i i ty of doing exact, algorithmic 
analysis, these tools uncover anomali-'S (i.e., cit-v'ations which are suspicious but 
are noc confirmed errors) and the designers must use intuition, experience and in- 
sight to determine whether or not a detected anomaly is in fact an error. Examples 
of consistency checking tools are: the TOPD consistency checker [Henderson 75a], 

event trace checkers [Stavely 79], and synchronization anomaly detectors 
[Bristow 79] . 


CONCLUSIONS 


DRICmSE MGE TS 
OF POOH QUALITY 


Even though we have not yet prepared a full implementation of DREAM, our develop- 
ment of DDN, along with its assessment and with our investigation into analysis 
techniques and other associated topics, has jivrn us some insights into the char- 
acteristics of effective development support systems, further, we have also 
gained some insight into major problems which remain to be solved on the way to 
achieving these systems. These insights, several of ttiem quite obvious with 20/20 
hindsight, are discussed in this concluding section. 


Some Lessons Learned 

Luuj'M‘,u' P <\‘ By building on lOPD as a base language, ard by not giving 
enougn thought to the inadvisability of having a large, complex language, we 
suffered a severe case of the "Second System Syndrome." We do not believe that we 
have unnecessary constructs. Nor do we feel that the constructs appear in conflict- 
ing forms. We do think that DDN should be more clearly decomposed into tlie family 
of interrelated languages which it actually is. Perhaps it is sufficient to par- 
tition the language along structure/behavior/organization lines, but that is not 
entirely clear at the moment. 

!P.pa)‘aWo>i of Couoi'imr,. Decomposition of the notational tools into an integrated 
collection of logically complete languages is part a larg'ir issue. /I... fools 
in a development system must serve a narrowly defined purpose and it is a mistake 
to make tools do "double duty." For examiile, having DDN be both a model descrip- 
tion language emd the basis for a data base query language is a mistake since it 
complicates the language and negatively impacts the ability to easily change either 
aspect of the' language. 

It is, of course, extremely desirable that a Tower of Babel situation be avoided. 

The point is that our experiences with DDN indicate one sliould define a number of 
small, interrelated, well-defined languages and tlien attempt to amalgamate them. 

We made the mistake of trying to put everything into one language from tiio very 
beginning. 

Tool Usage. A beautifully handcrafted banjo can be just a piece of art and not a 
musical instrument. So it is with software development tools - their value depends 
on their usefulness for software development rather than their elegance on more 
esoteric levels. It is imperative, therefore, that tools emerge througl' a natural 
selection process involving actual use. 

A well-established approach is to implement the tools, put them into use, and see 
how they are accepted. This is also an effective w.ty to "sell" tools to practi- 
tioners since, if they accept the tool then tliey will ask for more (a plienomenon 
which has been called the "Potato Chip Principle" [Nassi 80]). 

For a number of reasons, we did not take this approach in developing DREAM. Per- 
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evolve it as a result of thac usage. But it is equally important to do gedanken’ 
experiments away from the heat of battle - one has only to compare Pascal and 
Fortran to see this. In developing DON we have done a number of gedanken experi- 
ments and feel that this introspective, controlled usage of tools is an important 
development approach. 

Explomtion. DREAM provides little <Uy‘cot help for exploring and comparing alter- 
native designs. Designers may describe alternatives, assess them individually and 
compare the results. But, more sophisticated facilities are generally needed to 
help developers keep track of the alternatives, their sirnilarites and their 
differences. Facilities are also necessary to help developers trace back through 
a sequence of decisions. 

Eduoatiim. In teaching TOPD and DDN, we have found it possible, but difficult, to 
establish the right frame of mind for effective use of modelling-based tools. 

Even those more sophisticated students, who embrace good programming methodologies, 
tend to use the familiar to understand the unfamiliar and look at architectural 
design as something of the same nature as algorithm design, only more complicated. 
Further, the fact that TOPD and DDN have their heritage in programming languages 
fosters this reaction. We have found it mandatory to carefully establish the 
nature of architectural design prior to introducing design notations. 


Some Problems for the Future 

EuuaoUon. It probably overloads the world to create yet another paraphrase of 
MacArthur's famous saying, but it is true that "old programmers never die they 
just become designers.'’ And so it should be, since system designers must be rela- 
tively sophisticated programmers so that they create feasible designs. But this 
means that we cannot rely on experience being the "teacher" and must directly 
address the issue of educating developers in the ways to appropriately and effec- 
tively use tools and development environments, 

Larvjuages. Several proposals for primitives which should be in languages for pro- 
gramming distributed systems (e.g., [Andrews 77], [Hoare 78], [Liskov 79]) have 
duplicated some of the primitives found in DDN. This indicates that some of the 
primitives we developed for DDN are useful for the implementation-level descrip- 
tion of systems. We view this as desirable since it lessens the gap between a 
design and an implementation. But we also feel that blurring the distinction 
between design and implementation is not a good idea since it will allow, and per- 
haps even encourage, implementation decisions to be prematurely made. If the 
language-extension approach to preparing development environments is chosen, we 
feel it is critically important to allow the use of the primitive concepts (e.g., 
message transmission) without having to express all the details (e.g., message 
buffering constraints), 

Evalwxbion. We currently lack the techniques that will be necessary to assess the 
impact of tools and environments; there are many po'cci ocd advantages and disadvan- 
tages, but assessments are intuitive, subjective, ambiguous and contradictory. We 
need models of the development process and developers themselves. We need metrics 
of system quality and development methodology quality. And, we need some idea of 
how to conduct "small," experimental development projects in a way which allows 
valid inferences to be drawn concerning "large" efforts. 

Development Style. A particular need, in order to be able to prepare truly effec- 
tive environments, is for some understanding of how developers really carry out 
their work. Most development methodologies make the assumption that the process 
of development is, or can be, the orderlv progression of logical steps, and ration- 
alization of the process ir, no doubt, beneficial. But creative processes are 
nertorious fr."- their random ess and we need to understand the nature of this ran- 
domness rath ■t'han try t- ’"■'inate or control it. Only with such an understand- 
ing can erfec'.ivo hein b thr ih software clevelopment tools and environments. 
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Example DON Description 


In this appendix, we give a DDN description of an operating system that is struc- 
tured similarly to the T.H.E. operating system developed by Dijkstra and his 
colleagues [Dijkstra 68]. The description given here is essentially a translation 
of the description given in a notation that served as a basis for the DDN notation 
[•Riddle 72]. 

First we use the DDN Notation to give simple models of the devices managed by the 
operating system. 


[memory__control_uni t] : SUBSYSTEM CLASS; 

DOCUMENTATION; Items in this class of subsystems process 
requests for reading and writing of the real memory. 
Each request is in the form of an address within the 
real memory space. No account is taken in this model 
of the response to a read request. 

END DOCUMENTATION; 
channel: IN PORT; 

BUFFER SUBCOMPONENTS; address OF [real_address] 

END BUFFER SUBCOMPONENTS; 

END IN PORT; 

process: CONTROL PROCESS; 

MODEL; ITERATE; RECEIVE channel; 

END ITERATE; 

END MODEL; 

END CONTROL PROCESS; 

END SUBSYSTEM CLASS; 

[operator_console] : SUBSYSTEM CLASS; 

DOCUMENTATION; This models the console and the operator 
using it. 

END DOCUMENTATION; 
message_in: INPORT; 

BUFFER SUBCOMPONENTS; message OF [programjnessage] 

END BUFFER SUBCOMPONENTS; 

END IN PORT; 
reply_out: OUT PORT; 

BUFFER SUBCOMPONENTS; reply OF [opera tor_reply] 

END BUFFER SUBCOMPONENTS; 

END OUT PORT; 

operator: CONTROL PROCESS; 

MODEL; ITERATE; RECEIVE message in; 

SET reply TO ans; 

SEND reply_out; 

END ITERATE; 

END MODEL; 

END CONTROL PROCESS; 

END SUBSYSTEM CLASS; 

[card_reader]: SUBSYSTEM CLASS; 

DOCUMENTATION; This models the actual card reader. For 
purposes of this model, the card reader reads in one 
card at a time in response to requests from some part 
of ■ ■ e operatine vstem. 

E’. 'CUMENTATIuiS; 

END 'TFM CLASS; 


[card_reader]: SUBSYSTEM CLASS; 
request Jn: INPORT; 

BUFFER SUBCOMPONENTS; read_request OF [read_requestjnessage] 
END BUFFER SUBCOMPONENTS; 

END IN PORT; 
card out; OUT PORT; 

BUFFER SUBCOMPONENTS; card image OF [card] 

END BUFFER SUBCOMPONENTS; 

END OUT PORT; 
reader: CONTROL PROCESS; 

MODEL; ITERATE; RECEIVE request in; 

SET card jmage TO defined; 

SEND cardT out; 


END ITERATE; 
END MODEL; 

END CONTROL PROCESS; 
END SUBSYSTEM CLASS; 
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[printer]: SUBSYSTEM CLASS; 

DOCUMENTATION; The model is of a printer which receives 
carriage control signals separately from lines to be 
printed. It is not necessary that each carriage 
control signal be followed by a line to be printed, 

END DOCUMENTATION; 
carriage ^control : IN PORT; 

BUFFER SUBCOMPONENTS; signal OF [carriage_control_signal ] 
END BUFFER SUBCOMPONENTS; 

END IN PORT; 
contents: IN PORT; 

BUFFER SUBCOMPONENTS; line OF [printjine] 

END BUFFER SUBCOMPONENTS; 

END IN PORT; 
print: CONTROL PROCESS; 

MODEL; ITERATE; RECEIVE carriage_control ; 

MAYBE; RECEIVE contents; 

END MAYBE; 

END ITERATE; 

END MODEL; 

END CONTROL PROCESS; 

END SUBSYSTEM CLASS; 


In giving these models, we have indicated the need to have several different types 
of information. In some cases, we have indicated "values" that pieces of infor- 
mation should assume. This can be recorded more explicitly by using DDN monitor 
classes to record the names for these types of information and their possible 
"values" as delineated so far. 

[real_address]: MONITOR CLASS; 

END MONITOR CLASS; 

[program message]: MONITOR CLASS; 

DOCUMENTATION; messages sent by a program to the operator 
through the operator's console; 

END DOCUMENTATION; 

END MONITOR CLASS; 

[operator_reply] : MONITOR CLASS; 

STATE SUBSETS; ans END STATE SUBSETS; 

END MONITOR CLASS; 

[read_request_message] : MONITOR CLASS; 

END MONITOR CLASS; 
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[card]: MONITOR CLASS; 

STATE SUBSETS; defined END STATE SUBSETS; 

END MONITOR CLASS; 

[carriage_control_signal] : MONITOR CLASS; 

END MONITOK CLASS; 

[print__line] : MONITOR CLASS; 

END MONITOR CLASS; 

Before giving the operational parts of the operating system itself, another prim- 
itive part of the overall system that needs to be modelled is a program running 
under the operating system. The system is a mu 1 ti programmed one, so the class 
definition facilities are used to model a generic program running under the 
operating system. With respect to the devices and resources managed by the oper- 
ating system, the important thing to describe about a program is that it produces 
a nondeterministic sequence of uses of the various resources and devices. 

[program]: SUBSYSTEM CLASS; 
card request; OUT PORT; 

BUFFER SUBCOMPONENTS; read _request OF [read_request message] 

END BUFFER SUBCOMPONENTS; 

END OUT PORT; 
read_card: IN PORT; 

BUFFER SUBCOMPONENTS; cardjmage OF [card] 

END BUFFER SUBCOMPONENTS; 

END IN PORT; 

printer_control : OUT. PORT; 

BUFFER SUBCOMPONENTS; signal OF [carriage__control_signal 1 
END BUFFER SUBCOMPONENTS; 

END OUT PORT; 

1 ine_contents: OUT PORT; 

BUFFER SUBCOMPONENTS; line OF [print_line] 

END BUFFER SUBCOMPONENTS; 

END OUT PORT; 
to_operator: OUT PORT; 

BUFFER SUBCOMPONENTS; message OF [programjnessage] 

END BUFFER SUBCOMPONENTS; 

END OUT PORT; 
from_operator : IN PORT; 

BUFFER SUBCOMPONENTS; reply OF [opera tor_reply] 

END BUFFER ^BCOMPONENTS; 

END INPORT; 
access: OUT PORT; 

BUFFER SUBCOMPONENTS; address OF [virtual_address] 

END BUFFER SUBCOMPONENTS; 

END OUT PORT; 

END SUBSYSTEM CLASS; 

[virtual_address] ; MONITOR CLASS; 

STATE SUBSETS; defined END STATE SUBSETS; 

END MONITOR CLASS; 


'[program]: SUBSYSTEM CLASS' run: CONTROL PROCESS; 

MODEL; ITERATE; SELECT; 

(PERHAPS) COMMENT read operation; 

SET read_requost TO defined; 
SEND car'd”_request; 

RECEIVE read_card; 

(PERHAPS) COMMENT write operation; 

SET signal TO defined; 

SEND printer control; 

MAYBE; SET iTne TO defined; 
SEND line contents; 



END MAYBE; 

(PERHAPS) COMMENT interact with operator; 
SET message TO defined; 

SEND tojaperator; 

MAYBE; COMMENT not all messages 
reqjire a reply; 
RECEIVE from_operator ; 
END MAYBE; 


(OTHERWISE) COMMENT read or write a location 

in program's virtual 
memory space; 

SET address TO defined; 

SEND access; 


END SELECT; 
END ITERATE; 

END MODEL; 

END CONTROL PROCESS; 


19 


Notice that there is an inconsistency among these models - the operator always 
replies to each message that a program sends whereas the program does not always 
expect a reply. This could be uncovered by simulation-based testing at this 
level of modelling or by more formal analysis. This inconsistency will be re- 
moved when the operation of the system with respect to conversations between a 
program and the operator is elaborated later. 


The description of the operating system at this level of modelling may be com- 
pleted by giving models of the major operational parts of the operating system. 
First, the address translator which converts addresses in the virtual memory spaces 
of the programs into the actual memory space of the memory system: 


[address_translator] : SUBSYSTEM CLASS; 
virtual_space: IN PORT; 

BUFFER SUBCOMPONENTS; v address OF [virtual_address] 
END BUFFER SUBCOMPONENTS; 

END IN PORT; 
actual_space: OUT PORT; 

BUFFER SUBCOMPONENTS; a_address OF [real_address] 

END BUFFER SUBCOMPONENTS; 

END OUT PORT; 

END SUBSYSTEM CLASS; 


' [address_translator] : SUBSYSTEM CLASS' translate: CONTROL PROCESS; 
MODEL; ITERATE; RECEIVE vi rtual_space ; 

SET a_address TO defined; 

SEND actualjspace; 

END ITERATE; 

END MODEL; 

END CONTROL PROCESS; 


Before giving models of the other major processing portions of the operating sys- 
tems. the dpJLlnj±.innS- of the m'ores nf i nfov^inatjion nroroccoH hu ttia—cuc fom 


be updated. 
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'[read_requestjiiessage] : MONITOI? CLASS' 

STATE SUBSETS defined END STATE SUBSETS; 

'[carriage control_signal] : MONITOR CLASS' 

STATE SUBSETS defined END STATE SUBSETS; 

'[print line]: MONITOR CLASS' 

STATE SUBSETS defined END STATE SUBSETS; 

' [progranijiiessage] : MONITOR CLASS' 

STATE SUBSETS defined END STATE SUBSETS; 

'[real_address]: MONITOR CLASS' 

STATE SUBSETS defined END STATE SUBSETS; 

At this level of modelling, there are no further distinctions that can be made 
among the "values" of these pieces of information. 

The next processing module within the operating system is the handler of messages 
between the programs and the operator. At this level of modelling, the handler 
is either passing on a program's message, perhaps with some accesses to the 
handler's virtual memory space, or passing on the operator's reply, again possibly 
with some accesses to the handler's virtual memory space. The description of this 
class is parameterized with respect to the number of programs that can bo handled. 

[message_interpreter] : SUBSYSTEM CLASS; 

QUALIFIERS: ^'_of_programs END QUALIFIERS; 
message_in: ARRAY [1 : :#_of__programs] OF IN 

BUFFER SUBCOMPONENTS; message OF [program message] 

END BUFFER SUBCOMPONENTS; 

END INPORT; 

messagejout: OUT PORT; 

BUFFER SUBCOMPONENTS; message_to_operator OF [programjnessage] 

END BUFFER SUBCOMPONENTS; 

END OUT PORT; 
replv_in: IN PORT; 

BUFFER SUBCOMPONENTS; reply OF [operator_reply] 

END BUFFER SUBCOMPONENTS; 

END IN PORT; 

reply_out: ARRAY[l : :#jof_programs] OF OUT PORT; 

BUFFER SUBCOMPONENTS; reply_to_program OF [operator_reply] 

END BUFFER SUBCOMPONENTS; 

END OUT PORT; 

END SUBSYSTEM CLASS; 

[message_interpreter] : SUBSYSTEM CLASS; 
access: OUT PORT; 

BUFFER SUBCOMPONENTS; address OF [virtual_address] 

END BUFFER SUBCOMPONENTS; 

END OUT PORT; 

collector: ARRAY[1 : :#_of_program:>] OF CONTROL PROCESS; 

DOCUMENTATION; These control processes serve to funnel all 
of the messages from all of the programs into one stream 
and therefore to model that the message handler can 
handle the messages in any order. 

END DOCUMENTATION; 
message _stream: LOCAL OUT PORT; 

BUFFFR SUBCOMPONENTS; hold message OF [prograrnjnessage] 

' BUFFER SUr LMPONENTF 
.AL OUT PORT; 

Mn«n ; J ; frCfl'.'F - JNDrYl • 
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SET hold_nit!ssage(MY INDEX) TO message(MY_INDEX) ; 
SEND nipss'acn' strcam(MY INDEX); 

END ITERATE; 

END MODEL; 

END CONTROL PROCESS; 
handler: CONTROL PROCESS; 
getjiiessage: LOCAL IN PORT; 

BUFFER SUBCOMPONENTS; one of the messages OF [program message] 
END BUFFER SUBCOMPONENTS;’" 

END LOCAL IN PORT; 

MODEL; ITERATE; RECEIVE get message; 

ITERATE PERHAPS; 

SET address TO defined; 



SEND access; 

END ITERATE; 

SET message^ to operator TO defined; 

SEND message put; 

MAYBE; COMME’N’T reply not always expected; 
RECEIVE renly in; 

ITERATE PERHAPS; 

SET address TO defined; 

SEND access; 

END ITERATE; 

FOR SOME i IN [1 : •J_of_programs] ; 

SET rGply_to__program( i ) TO defined; 
SEND reply_ou't(i) ; 


END FOR; 

END MAYBE; 

END ITERATE; 

END MODEL; 

END CONTROL PROCESS; 

CONNECTIONS; 

FOR ALL i IN [1 : : #_of_programs] ; 

PLUG(collector( i ) [message stream, handler [get jiessage) ; 


END FOR; 

END CONNECTIONS; 
END SUBSYSTEM CLASS; 
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The connections among the ports of the control processes serve, as the comment in 
the documentation of the collector control processes indicates, to set up a message 
communication network which funnels all of the messages into one stream. This net- 
work, when there are four programs, may be graphically represented as in Figure 2. 

A further elaboration of the message interpreter, given later, will indicate that 
an alternative communication network is really used. This one, and the models of 
the control processes, serve to give an abstract description of the interactions 
of this part of the operating system with the other parts of the operating system. 

The remaining major part of the operating system is the spooling subsystem. In 
the following model of this part, we exhibit an alternative to funnelling message 
from many sources into one stream - the spooler is set up to poll the various 
sources of requests in some nondeterministic (at this point anyway) order. 



[spool ing_systein]: SUBSYSTEM CLASS; 
access: OUT PORT; 

BUFFER SUBCOMPONENTS; address OF [virtual_address] 

END BUFFER SUBCOMPONENTS; 

END OUT PORT; 
tojoperator: OUT PORT; 

BUFFER SUBCOMPONENTS; message OF [programjnessage] 

END BUFFER SUBCOMPONENTS; 

END OUT PORT; 
from_operator; IN PORT; 

BUFFER SUBCOMPONENTS; reply OF [opera tor_reply] 

END BUFFER SUBCOMPONENTS; 

END IN PORT; 

END SUBSYSTEM CLASS; 

[spool ing__sys tern] : SUBSYSTEM CLASS; 

QUALIFIERS; #_of_user programs END QUALIFIERS; 
read_request_in: ARRAY[1 : :^_of_userj3rograms] OF IN PORT; 

BUFFER SUBCOMPONENTS; program_read_request 

OF [read_request_message] 

END BUFFER SUBCOMPONENTS; 

END IN PORT; 

read_request_out: OUT PORT; 

BUFFER SUBCOMPONENTS; read_request OF [read_request_message] 
END BUFFER SUBCOMPONENTS; 

END OUT PORT; 
read_car • : IN PORT ; 

BUFFf SUBCOMPONP'^S; cardjmage OF [card] 

• ’UFFER SUBCOMPONENTS; 

EHD 1'* POfif; 
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BUFFER SUBCOMPONENTS; dolivered card image.' OF [card] 

END BUFFER SUBCOMPONENTS; 

END OUT PORT; 

printer control in: ARRAY[l::i/ of user _progranis] OF IN PORT; 

BUFFER SUBCOMPONENTS; signal' OF Icarriage control signal! 

END BUFFER SUBCOMPONENTS; 

END IN PORT; 

printer controljout: OUT PORT; 

BUFFER SUBCOMPONENTS; signal__to printer 

OF [carriage control signal] 

END BUFFER SUBCOMPONENTS; 

END OUT PORT; 

line_contents__in: ARRAY[1::^ of user programs] OF IN PORT; 

BUFFER SUBCOMPONENTS; line OF [prfnt line] 

END BUFFER SUBCOMPONENTS; 

END IN PORT; 

line contentsjDut: OUT PORT; 

BUFFER SUBCOMPONENTS; 1 ine„to j)r inter OF [print line] 

END BUFFER SUBCOMPONENTS; 

END OUT PORT; 
spooler: CONTROL PROCESS; 

MODEL; ITERATE; SELECT; 

(PERHAPS) COMMENT send a message to the 
operator; 

SET message TO defined; 

SEND to joperator; 

MAYBE; RECEIVE from_operator ; 

END MAYBE; 

(PERHAPS) COMMENT read or write a location 

in virtual memory space; 

SET address TO defined; 

SEND access; 

(OTHERWISE) COMMENT service a request 

from one of the user 
programs; 

FOR SOME i IN [1 :: if_of_pser programs] ; 
MAYBE; RECEIVE read]_request_in(i ) ; 

SET read__request TO defined; 
SEND read’ requestjaut; 

RECEIVE read_card; 

SET del i vered_jcard_image(i 1 
TO card”iniage; 

SEND read card out(i); 

ELSE: 

RECEIVE printer_control__in(i ) ; 
SET signal__to_printer 
TO defined; 

SEND printer control out; 

MAYBE; 

RECEIVE 1 ine_contents_in( i ) ; 
SET 1 ine_tojarinter 
TO 1 ine(i ) ; 

SEND 1 ine_contents out; 

END MAYBE; 

END MAYBE; 

END SELECT; 

END ITERATE; 

END MODEL; 

END CONTROL PROCESS; 

END SUBSYSTEM CLASS; 
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This concludes the description of all of the components for the operating system. 24 
The remaining step at this level of modelling is to describe the operating system 
itself, indicating its componentry and the network of communication pathways 
among the components. 


[operating system]: SUBSYSTEM CLASS; 

QUALIFIERS;^ of user programs END QUALIFIERS; 

SUBCOMPONENTS; ” 

programs ARRAY[1 : :#_of user__programs] OF [program], 
memory system OF [memory jcontrol__system] , 
console OF [operator_console] , 
reader OF [card^reader] , 
hard_copy OF [pFinter], 
translator OF [address__translator] , 

interpreter OF [messagF_interpreter()S<_of_usar programs+1)] , 
spool OF [spooling__system(j5'_pf__user_prograins)J 
END SUBCOMPONENTS; 

CONNECTIONS; 

PLUG (translator [actual _space, memoryjsystem | channel ) ; 

( i nterpreter [messagejaut , consol 
(console] replyjaut, interpreter 
(interpreter|access, translator 
(spool |read_request_out, reader 
(reader I cardjDut, spool |read_card); 

(spool printer_control_out, hard_copy jcarriagejcontrol ) ; 
(spool 1 ine_contents_out, hardjcbpy jcoi ^.ents) ; 

(spool access, translator] virtual_space) ; 

(spool tojaperator, interpreter]messago_in(l)) ; 

( interpreter ]reply_out( 1) , spool ]from_operator) ; 
i IN [1::# of__userj)rograms] ; 

(program(iT]card_request, spool ] read_request__in( i ) ) ; 


PLUG 
PLUG 
PLUG 
PLUG 
PLUG 
PLUG 
PLUG 
PLUG 
PLUG 
PLUG 
FOR ALL 
PLUG 
PLUG 
PLUG 
PLUG 
PLUG 


e]message_in) ; 
replyjn) ; 
virtual_space) ; 
request_in) ; 


(spool [read card_out(i), program( i ) ] read_card") ; 


(program( i ) 
(program(i ) 
(program( i ) 


PLUG 

PLUG (program(i) 
END FOR; 

END CONNECTIONS; 

END SUBSYSTEM CLASS; 


printer_control , spool ]printer_control_in(i )) ; 
1 inejco'ntents , spool ] 1 ine_contents_in( i ) ) ; 
tojaperator , interpreter ]message_in(i^■l ) ) ; 


( interpreter ] reply_out( i+1 ) , program( i ) ] from operator); 


access, translator ]virtual_space) ; 


The communication network that is set up by this description is essentially that 
given in Figure 1 in [Riddle 72], 

**★******★ 

In [Riddle 72] the level of modelling for the operating system is elaborated for 
each of the major operational parts of the operating system. For purposes of ex- 
ample, we will carry that elaboration out for the message_interpreter and 
address_translator parts of the operating system. The elaboration of the 
spool ing_sys tern, using DDN, is left as an exercise. 


For the address_translator, we need first to model the external storage that is 
used to hold paged-out portions of the virtual spaces. 


[external_storage]: SUBSYSTEM CLASS; 
read_request: IN PORT; 

BUFFER SUBCOMPONENTS; request OF [io_request] 

END BUFFER SUBCOMPONENTS; 

END IN PORT; 
write_request: IN POR 

BUFFER SUBCOMPONF''' te__request OF [io_request] 

' BUFFER SUu'-'jrii UI1..NTS ; 


END BUFFER CONDITIONS; 

END IN PORT; 
read done: OUT PORT; 

BUFFER SUBCOMPONENTS; signal OF [io done signal] 

END BUFFER SUBCOMPONENTS; 

END OUT PORT; ' 
write done: OUT PORT; 

BUFFER SUBCOMPONENTS; write__signal OF [io done_signal] 

END BUFFER SUBCOMPONENTS; 

END OUT PORT; 
io: CONTROL PROCESS; 

MODEL; ITERATE; MAYBE; 

RECEIVE read_request; 

SET signal TO accomplished; 

SEND readjdone; 

ELSE; 

n»Tr.T«,r RECEIVE wri te_request; 

KiGiNAL’ PA'GEi fgr SET write signal TO accomplished; 

iKiOa fiUALITW SEND writejdone; 

MAYBE;' 

END ITERATE; 

END MODEL; 

END CONTROL PROCESS; 

END SUBSYSTEM CLASS; 

[io_request] : MONITOR CLASS; 

STATE SUBSETS; read, write END STATE SUBSETS; 

END MONITOR CLASS; 

[io_done_signal]: MONITOR CLASS; 

STATE SUBSETS; accomplished END STATE SUBSETS; 

END MONITOR CLASS; 

We have used the buffer conditions construct of DDN to indicate that only write 
requests may come in through the write_request port. 

We also need a semaphore. 

[semaphore]: MONITOR CLASS; 

STATE SUBSETS; uninitialized, zero, one 
END STATE SUBSETS; 

DOCUMENTATION; This is a binary semaphore which may be used 
for mutual exclusion. The operation of the procedures is 
not elaborated here - they may be "programmed" using 
signals and waits upon condition variables. 

END DOCUMENTATION; 
initialize: PROCEDURE; 

TRANSITIONS; uninitialized one 
END TRANSITIONS; 

END PROCEDURE; 
p: PROCEDURE; 

TRANSITIONS; one ->■ zero; zero -»■ zero 
END TRANSITIONS; 

END PROCEDURE; 
v: PROCEDURE; 

TRANSITIONS; zero ->• one 
END TRANSITIONS; 

END PROCEDURE; 

END MONITOR CLASS; 


Now we can specify the parts of the add ress t ranslato r as control processes. 


[address^translator] : SUBSYSTEM CLASS; ' 26 

virtua'l space: INPORT; 

BUFFt'R SUBCOMPONENTS; v address OF [virtual jiddress] 

END BUFFER SUBCOMPONENTS; 

END IN PORT; 
actual space: OUT PORT; 

BUFFER SUBCOMPONENTS; a address OF [rea l^ackiress] 

END BUFFER SUBCOMPONENTS; 

END OUT PORT; 

SUBCOMPONENTS; 

storage OF [external_storage] , 
mutex OF [semaphore] 

END SUBCOMPONENTS 
check: CONTROL PROCESS; 

set_up_swap: LOCAL OUT FORT; 

BUFFER SUBCOMPONENTS; signal OF [activate_signal] 

END BUFFER SUBCOMPONENTS; 

END LOCAL OUT PORT; 

BODY; ITERATE; RECEIVE virtual_space; 
mutex. p; 

COMMENT access the page tables; 
mutex. v; 

IF PERHAPS 

THEN a_address.assign; 

SEND actual_space; 

ELSE signal .assign; 

SEND set_up__swap; 

END IF; 

END ITERATE; 

END BODY; END CONTROL PROCESS; END SUBSYSTEM CLASS; 

In this control process definition, we have used a body textual unit to indicate 
that what is being defined is an actual part of the subsystem rather than just 
a model. Within the body, we have used nondeterminism to indicate that it is not 
yet completely specified as to how tf»e decision is made as to whether the page is 
in the actual memory system or on external storage. This is not really legal in 
DDN - a legal description would require the definition of a flag variable that 
was set (nondeterministically) to either true or false within the critical section 
and was used to control the subsequent flow of processing. 

The definition of the address_translator is completed with the following textual 
units . 


[address_translator] : SUBSYSTEM CLASS; 
swap: CONTROL PROCESS; 

wait_for _j‘'ctivation: LOCAL IN PORT; 

BUFFER .SUBCOMPONENTS; signal OF [active ' e_signal ] 
END BUFFER SUBCOMPONENTS; 

END LOCAL IN PORT; 
read_request : LOCAL OUT PORT; 

BUFFER SUBCOMPONENTS; request OF [io_request] 

END BUFFER SUBCOMPONENTS; 

END LOCAL OUT PORT; 
read_done: LOCAL IN PORT; 

BUFFER SUBCOMPONENTS; signal OF [iojone signal] 

END BUFFER SUBCOMPONENTS; 

END LOCAL IN PORT; 
write _request: LOCAL OUT PORT; 

BUFFER SUBCOMPONENT'' ■. wri te_request OF [io_request] 
END BUFFER ’ONENTS; 

END LOCAL OUT , 
i te^dcji.e : LOCAL lii i w..i , 
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END BUFFER SUBCOMPONENTS; 

END LOCAL IN PORT; 

BODY; ITERATE; RECEIVE wai t,/or_acti vation; 

niutex.p; COMMENT chock for page unchangod; 
mutex . V ; 

IF PERHAPS 

THEN write jequest. assign; 

SEND w'rite request; 

RECEIVE write done; 

END IF; 

request. assign; 

SEND read_rcquest; 

RECEIVE read done; 

niutex.p; COMMENT update the page tables; 
mutex.v; 

a address. assign; 

SEND actua1_space; 

END ITERATE; 

END BODY; 

END CONTROL PROCESS; 

END SUBSYSTEM CLASS; 

[address_translator] : SUBSYSTEM CLASS; 

CONNECTIONS; 

PLUG (check|set_up__swap, swapjwai t_for jictivation) ; 

PLUG ( swap! read__request, storage j read_7equest) ; 

PLUG (storage I readjdone, swap | read_dohe) ; 

PLUG (swap|write_request, storage|write_request) ; 

PLUG (storage|write_done, swapjwritejdone) ; 

END CONNECTIONS; 

The graphical representation of this connection network is essentially that appear- 
ing as Figure 6 in [Riddle 72]. The major difference is that in the Hgure in 
[Riddle 72], the semaphore is represented as a link process because the precursor 
of DDN did not have the concept of monitor class. 

This elaboration indicates one of the major purposes of control processes in addi- 
tion to their role in modelling. When components within a subsystrii arc partic- 
ular to that subsystem, a body for a control process .nay be prepared to indicate 
the algorithm for the message handling carried out by the component. DDN would 
allow a class definition to be preparuJ and then an instance of that class to be 
declared as a subcomponent within the subsystem - as was done for the external 
storage component. But it is often sufficient to indicate the component directly 
as a control process body, and this serves the additional purpose of drawing a 
direct correspondence between the subsystem's modelled beiavior and the operation 
of the subsystem's components. 

In these textual units, we have again used procedures named assign . We should 
define these wilhin the class definitions, but this is not really very illustra- 
tive, so we will skip that. 

For the elaboration of the message jnterpreter , we will not only specify the 
operation of some of its components', but will also elaborate the description with 
respect to the types of messages that are processed. The intent of this elabora- 
tion is to specify some aspects of conversations between a program and the opera- 
tor. First, we elaborate the types of messages that can be sent by the programs 
to the operator. 
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[programjTiessage] : MONITOR CLASS; “ 

STATE SUBSETS; write, write and wait, terminate 
END STATE SUBSETS; 
set_to terminate: PROCEDURE; 

TRANSITIONS; > terminate 
END TRANSITIONS; 

END PROCEDURE; 

END MONITOR CLASS; 

We have included the procedure set__to_terminate because it will be needed in later 
descriptions. The state «:ubsets irfdicate that the program may send a message to 
the operator without a f fiy expected (write), send a message with a reply expected 
(write_and_wait) , or indicate that the conversation with the operator may be termi- 
nated. 

In the elaboration of the message ^interpreter, it will attach an identification 
of the originating program to the’ message before passing it on to the operator. 

Thus we need a class definition that describes these coded messages. 

[encodedjnessage] : MONITOR CLASS; 

QUALIFIERS; ^_of jDrograins END QUALIFIERS; 

STATE VARIABLES; 

id: VALUES (1::// ofjDrograms) , 
content: VALUES Tmessage, null) 

END STATE VARIABLES; 

STATE SUBSETS; 

write: content=message>> , 

write_and_wait: <<--, content=message>> , 
terminate: content=null>-> 

END STATE SUBSETS; 
assign: PROCEDURE; 

PARAMETERS: 

id VALUE OF [l : :i|*_of ^programs] , 
message_t6_be_sent VALUE OF [programjnessage] 

END PARAMETERS; 

TRANSITIONS; message__to_be_sent=write ->-write, 

message3o_be_sent=write_and_wai t -v write__ and_wait, 
message to_be_sent= terminate terminate 
END TRANSITIONS; 

END PROCEDURE; 

END MONITOR CLASS; 

We also need similar class definitions for the messages sent from the operator to 
the program. 

[operator_reply] : MONITOR CLASS; 

STATE SUBSETS; ans, suspend 
END STATE SUBSETS; 
assign: PROCEDURE; 

PARAMETERS; 

reply_to_be_sent VALUE OF [encoded_reply] 

END PARAMETERS; 

TRANSITIONS; rep jy_to_be_sent=ans and 
END TRANSITIONS; 

DOCUMENTATION; This procedure may not be legally invoked 
when the operator has sent a suspend message. 

END DOCUMENTATION; 

END PROCEDURE; 

END MONITOR CLASS; 


[encoded_rep1y]: MONITOR CLASS; 

QUALIFIERS;//j)f_programs END QUALIFIERS; 

STATE VARIABLES; 

id: VALUES (X’.’J of programs) , 
content: VALUES Tmessago, null) 

END STATE VARIABLES; 

STATE SUBSETS; 

ans: content=message>> , 

suspend: content_nul ■ 

END STATE SUB<^ETS; 
find id: PROCEDURE; 

P?\RAMETERS ; 

id RESULT OF [1::^ ofjDrogr 
END PARAMETERS; 

END MONITOR CLASS; 

With these monitor classes, we are in a position to give the elaboration of the 
message interpreter. 

[message_interpreter] : SUBSYSTEM CLASS; 

QUALIFIERS; //_of orograms END QUALIFltRS; 
message in: ARRAY[1 : :#_of__programs] OF INPORT; 

BUFFER SUBCOMPONENTS; message OF [prograinjuessage] 

END BUFFER SUBCOMPONENTS; 

END IN PORT; 
messagejQUt: OUT PORT; 

BUFFER SUBCOMPONENTS; message _to__operator 

OF [encod’edjiiessage( if*jof_programs ) ] 

END BUFFER SUBCOMPONENTS; 

END OUT PORT; 
reply_in: INPORT; 

BUFFER SUBCOMPONENTS; reply OF [encoded_reply(/'_of_programs)] 

END BUFFER SUBCOMPONENTS; 

END IN PORT; 

reply_out: ARRAY[1 : :#_of_programs] OF OUT PORT; 

BUFFER SUBCOMPONENTS- reply_toj3rogram OF [opera tor_reply] 

END BUFFER SUBCOMPiMENTS ; 

END OUT PORT; 
access; OUT PORT; 

BUFFER SUBCOMPONENTS: address OF [vi rtual_addrcss] 

END BUFFER SUBCOMPONENTS: 

END OUT PORT; 

SUBCOMPONENTS; 

mutex OF [semaphore] 

END SUBCOMPONENTS; 

transfer: ARRAY[l : :#_of_programs] OF CONTROL PROCESS; 
passjTiessage Jn : LOCAL OUT PORT; 

BUFFER SUBCOMPONENTS; passedjnessage OF [programjnessage] 

END BUFFER SUBCOMPONENTS; 

END LOCAL OUT PORT; 

MODEL; ITERATE; RECEIVE messageJn(MYJNDEX) ; 

SET passed_message(MY_INDEX) TO message(MY_INDEX) ; 
SEND pass_messaae_in(MY__INDEX) ; 

END ITERATE; 

END MODEL; 

END CONTROL PROCESS; 

encode; ARRAY[1 : :#jDf programs] OF CONTROL PROCESS; 
getjiiessage_in: LOCAL IN PORT; 

BUFFER SUBCOMPONENTS; message from_prograni_or decode 

OF"Tprogram message]] 

END BUFFER SUBCOMPONENTS; 

END LOCAL IN PORT; 

, BUDY.; ITERATE: _ 



RECEIVE getjnessage__in(MY_INDEX) ; 
mutex.p; 

WHILE message from _program_or_decode(MY_INDEX) 
wr i t'e_a ndjva i t ; 

ITERATE PERHAPS; 
address. assign; 

SEND access; 

END ITERATE; 

messageto_operator.assign(MY_INDEX, 

~ message_from_programj3r__decode(MY_INDEX) ) ; 

SEND messagejDut; 

RECEIVE get inessage_in(MY_INDEX) ; 

END WHILE; " 

IF message_frnm_program_or_decode(MY_INDEX) 

“ wr i tfi * 

THEN; ITERATE PERHAPS; 

* address .assign; 

SEND access; 

END ITERATE; 

message_to __operator .assign(MY_INDEX, 
message JfromjDrogram_or_decode(MY_INDEX) ) ; 
SEND messagejDUt; 

END IF; 
mutex. v; 

END ITERATE; 

END BODY; 

END CONTROL PROCESS; 
decode: CONTROL PROCESS; 

transfer_suspend: ARRAY[1 : ;#_of_programs] OF LOCAL OUT PORT; 
BUFFER SUBCOMPONENTS: termjnessage OF [programjTtessage] 

BUFFER SUBCOMPONENTS; 

END LOCAL OUT PORT; 

LOCAL SUBCOMPONENTS; 

id OF [1 : :#_of programs] 

END LOCAL SUBCOMPONENTS; 

BODY; ITERATE; 

RECEIVE reply in; 
reply.find_idTid) ; 

IF reply = suspend 

THEN; term_message(id) .set_to_terminate; 

SEND transfer_suspend( id) ; 

ELSE; reply_to_program(id) .assign(reply) ; 

SEND reply out(id) ; 

END IF; 

END ITERATE; 

END BODY; 

END CONTROL PROCESS; 

CONNECTIONS; 

FOR ALL i IN [1 : :#_of jDrograms] ; 

PLUG (transfer(i ) |pass message_in, 

encoderi ) |get message_in); 

PLUG (decode I transfer_suspendX'i ) , 

encode(i ) |get_message_in) ; 

END FOR; 

END CONNECTIONS 
END SUBSYSTEM CLASS; 

This completes thp elaboration of the message ^interpreter. It remains to update 
the model of the oerator's console to reflect the new level of modelling 
achieved in th?' “1 of the rnessage_ i nterpreter . 


[operator ^console] : SUBSYSTEM CLASS; 

DOCUMENTATION; This models the console and the operator 
using it. 

END DOCUMENTATION; 
message_in: IN PORT; 

BUFFER SUBCOMPONENTS; message OF [encoded niessage(#_of programs ) ] 

END BUFFER SUBCOMPONENTS; 

END IN PORT; 

END SUBSYSTEM CLASS; 

[opera tor_console]: SUBSYSTEM CLASS; 
reply__out: OUT PORT; 

BUFFER SUBCOMPONENTS; reply OF [encoded reply(#_of_programs)] 

END BUFFER SUBCOMPONENTS; 

END OUT PORT; 

operator: CONTROL PROCESS; 

LOCAL SUBCOMPONENTS; id OF [id: ://_of_programs] 

END LOCAL SUBCOMPONENTS; 

BODY; ITERATE; 

RECEIVE message in; 
message. find_idTid) ; 

IF message ■- wri te_and_wai t ; 

THEN; reply. set_’id( id ) ; 
reply.set__type; 

ORIGINAL' PAGE R reply_out; 

Qfi £QQ& QUalitv "" suspend AND PERHAPS; 

THEN; reply. set_some__id; 
reply .setjiiessage; 

SEND reply out; 

END IF; 

END IF; 

END ITERATE; 

END BODY; 

END CONTROL PROCESS; 

QUALIFIERS; //_of jDrograms END QUALIFIERS; 

END SUBSYSTEM CLASS; 

This description requres the definition of four procedures to operate upon encoded 
replies, 

'[encodedj'eply]: MONITOR CLASS' setjd: PROCEDURE; 

PARAMETERS ; 

id VALUE OF [1 : :7/_of_programs] 

END PARAMETERS; 

END PROCEDURE; 

'[encoded reply]: MONITOR CLASS' set_type: PROCEDURE; 

TRANSITIONS; -v ans, ->• suspend 
END TRANSITIONS; 

END PROCEDURE; 

' [encoded_reply] : MONITOR CLASS' set_some_id: PROCEDURE; 

END PROCEDURE; 

' [encoded_reply] : MONITOR CLASS' setjnessage: PROCEDURE; 

TRANSITIONS; -v ans 
END TRANSITIONS; 

END PROCEDURE; 

Note the use of nondeterminism in the procedure set_type. This makes the descrip- 
tion of the operation of the operator_consol e be a nondeterministic one even 
though a body is given for the control process. 


